As a result of the increase, apparent for years, in process information data which must be captured, processed and stored by means of facility or process information management systems, and made available by means of servers at the request of clients or operators, there is also an increase in the demands on databases or history storages of such systems.
In the endeavour to respond better to such increasing demands on facility or process information management systems, various system structures have already been proposed. For example, DE 102 43 065 B4 describes a system, which features an integrated history functionality, for operating and monitoring a production process, wherein a history database is provided in addition to means for supplying and processing process information data. The system described therein is designed such that the properties of operating and monitoring systems and of history systems are combined, the required process information data being captured only once.
Known facility or process information management systems (PIMS) can be categorized into two groups as explained below with reference to a facility structure.
FIG. 2 illustrates three structural levels, namely a controller level, a monitoring and operating (B&B) level and a PIMS level. In the monitoring and operating level, operator workstations 2, a realtime history database 6 and connectivity servers 3 are connected together via a network, wherein controller cabinets 4 of the controller level are linked to the connectivity servers 3. The B&B level is connected to a PIMS server 7 via a firewall 8. At the PIMS level, office PCs as clients 1 are connected to the PIMS server 7 via a first data transmission entity 9. Furthermore, Internet users 5 also have access to the PIMS server 7 via the first data transmission entity 9. Whether both PIMS server 7 and a history database 6 are both present, and in which configuration, depend on the solution framework concerned. The B&B and controller levels together form a so-called distributed control system (DCS).
A first known group includes systems in which, in the context of so-called process information management solutions, process information management (PIMS) servers (7, FIG. 2) which can be used in a flexible manner form the data backbone for the office environment (information backbone), this being isolated from the DCS. These PIMS systems are therefore independent from the DCS, and process information data is typically transmitted from the DCS as compressed data and at relatively low speed.
Advantageous properties of such systems using PIMS servers are that they are flexibly reconfigurable from the perspective of the PIMS level, e.g. with regard to entering, deleting and editing measurement point histories, that historical data can be stored over many years, typically 5 to 10 years, that historical values can be overwritten/modified, and that a large number of standard APIs (standard programming interfaces) such as ADO, OLE-DB and any desired web interfaces are available for linking data to the office environment in a simple manner.
Disadvantageous properties of systems using additional PIMS servers are that, due to the large volume of data and the use of standard databases, the long-term storage is generally only possible as compressed MIN, MAX or AVG data (so-called aggregate values), that overwriting is only possible in the preconfigured time slot pattern of the relevant measurement point, that the system is not suitable for storing raw data, that it is not possible to meet realtime demands, in particular due to sometimes long or non-deterministic response times when writing, reading or during configuration, and finally that laboratory value input is only possible using an additional table structure, and that true equal treatment as raw value or as compressed aggregate value is therefore impossible.
The second known group includes systems in which a proprietary database (6 in FIG. 2) is integrated in the DCS in each case, wherein said database is able to meet the realtime demands of the DCS but is not as flexible in use as the PIMS server of the first group. In the DCS area, however, the flexibility in terms of online reconfiguration and other database operations, such as e.g. deleting or overwriting subareas in any desired time slot pattern, was previously also hardly necessary since the relevant facility was typically only planned, configured and started once. Moreover, flexibility was also difficult to implement, since proprietary databases were primarily designed in such a way that large amounts of data could be gathered as quickly as possible, stored, and presented to the facility operator in the most performant manner possible, i.e. large volumes of data at high speed, typically in the form of graphical trends.
Advantageous properties of such systems including a DCS proprietary database are that they offer high performance and provide realtime capability for storage and reading.
Disadvantageous properties of the systems including a DCS proprietary database are that they offer no flexibility or only restricted flexibility in terms of online configuration, that too little time is available for PIMS demands, that they allow no data export or only very limited data export to the office environment, that only a rudimentary special API is provided for DCS clients, representation of trends and graphical imaging, that overwriting the history is only possible in very limited form, and that laboratory value input is not normally possible.
Using standard means such as SQL Server with a specially optimized data model and additional programming resources, the solutions of both cited system groups can be combined in such a way that advantages of both variants can be used, wherein the disadvantages with regard to realtime properties and performance properties would also be combined, however.